Signatures have been around for thousands of years, from John Hancock's signature on the Declaration of Independence, to a simple sailor assigning an “X” to an enlistment paper for a sailing vessel, to a farmer enlisting in a Roman legion for the first time. All of these examples convey the intent of signing party that they are who they say they are and that they will be “bound” to the signed document (or the terms thereon). In more recent times, electronic signatures have been used to covey the same concept. One such variation on an electronic signature is a digital signature. Such digital versions of a signature may be more secure and verifiable than ordinary electronic signatures.
Digital signatures are commonly produced using public key cryptographic technology through the use of standards-based, certificate authority-focused public key infrastructure (PKI); or standards-based Pretty Good Privacy (PGP); or, the nearly equivalent to PGP, GNU Privacy Guard (GPG) public key infrastructure. While these techniques are mathematically appealing, the management necessities of the public key paradigm may have produced enough technical confusion with typical computing users to have worked against their broad acceptance. Further, it seems that juridical acceptance of PKI digital signatures has not been established for day-to-day use. Such techniques are generally harbored and encouraged by computing users who are well-versed in computer science, mathematics, or both.
Digital Signatures
Various references provide a number of necessary building blocks for secure and juridically useful digital signatures. These references include: Bruce Schneier's, Applied Cryptography: Protocols, Algorithms, and Source Code in C, 2nd Edition, Chapter 2, Section 2.6 Digital Signatures; along with technically acceptable articles regarding “Cryptographic Hash Function” and “Digital Signature.”
The basis for a digital signature is the use of a cryptographic hash function as a secure one-way hashing function that mathematically binds a document/information in such a manner that:                1) It is relatively easy, but not necessarily quick, to compute the fixed-length cryptographic hash value for any given document/information where the fixed length cryptographic hash value is generally of considerably shorter length than the document/information;        2) It is not feasible to generate a document/information that possesses a given, valid cryptographic hash value;        3) It is not feasible to modify a document/information without significantly changing the cryptographic hash value; and/or        4) It is not feasible to find two different documents or contextually similar but not digitally equal pieces of information with the same cryptographic hash value. This concept is sometimes referred to as collision resistance.        
Examples of important cryptographic hash functions are MD5, SHA-128, SHA-256, SHA-512, and RipeMD-160. However, MD5 and SHA128 may riot be able to satisfy all of the above requirements, particularly the last item identified above. In order to guard against the possibility that similar problems may arise with SHA256 and SHA512, the U.S. National Institute of Standards and Technology (NIST) opened a public competition on Nov. 2, 2007 to develop a new cryptographic hash algorithm/function, which converts a variable length message into a short “message digest” that can be used for digital signatures, message authentication, and many other security applications in today's digital age. The result of this competition will be a cryptographic hash function named SHA-3 and will augment the hash algorithms/functions currently specified in the Federal information Processing Standard (FIPS) 180-3, Secure Hash Standard. The competition is expected to end during late 2012.
Binding an identity value that is juridically-undeniably associated with the signer to a document/information is necessary for a trustworthy digital signature. For convenience and efficiency this identity may be bound to the cryptographic hash function value of the document/information. In addition to fulfilling the requirements of the cryptographic hash function, the resultant digital signature is required to provide measures of signature authenticity, high integrity, non-forge-ability, and non-repudiation. Namely:                1) a digital signature is authentic if the means of authentication provides proof that the identity value that is tightly bound to the document/information is secure and tightly bound to the user associated with the identity value;        2) a digital signature achieves high integrity if the digital signature method produces proof that all digitally equivalent copies of the “digitally signed” document/information are proven to have been unchanged since the production of the digital signature;        3) a digital signature is required to exhibit non-forge-ability by providing proof that the identity associated with the signer can not have been associated with someone else; and        4) a digital signature is required to produce non-repudiated juridical evidence that the user associated with the authenticated identity of the high integrity document/information produced the digital signature.        
Non-repudiation tends to be the Achilles Heel for authenticated digital signatures. Authentication of non-repudiation is generally dependent on the undeniable use of “something only the signer knows” or “something only the signer possesses”. For example, the attributed signer could readily deny having produced a digital signature because someone else masqueraded as the signer by virtue of having acquired the use of the key(s) necessary to generate the authenticity of the digital signature. Thus, the achievement of non-repudiation must be produced with great care and with juridical soundness.
Presently, public key infrastructure (PKI) is the presumed technology for producing digital signatures on digital documents/information. It may be instructive to discuss the means by which PKI attempts to achieve the requirements for producing digital signatures.
PKI Digital Signatures
PKI digital signatures use the private key of a public key technology key pair to encrypt the cryptographic hash function value of a document/information. This resultant value binds the document to the public-private key pair. The public key is further bound into a cryptographic structure called a certificate. This certificate contains identity information which is presumably vouched by a known “authority” that the certified identity is associated with the user of the public-private key pair.
The typical PKI digital signature capability allows the use of essentially any cryptographic hash function. However, the cryptographic hash functions that are used are generally selected from the list of functions that are outlined in the above section on digital signatures, namely MD5, various SHA implementations, and RipeMD-160 cryptographic hash functions. As explained earlier, except for the MD5 and SHA-128 hashes, these hash functions presently satisfy the list of requirements for a cryptographic hash function. Other unlisted hash functions, such as GOST, HAVAL, Whirlpool, fulfill the cryptographic hash function requirements but are not typically relied upon for both technical and business reasons. The authenticity of the digital signature is proven by being able to use a PKI certificate to acquire the public key of a PKI public-private key pair for use in decrypting the cryptographic hash function value. Successful decryption proves the authenticity of the digital signature. Subsequent comparison of a newly calculated cryptographic hash value on the document/information to the successfully decrypted cryptographic hash offers proof of digital signature integrity.
The cryptographic quality of the cryptographic hash function as applied to a document/information offers the necessary proof of the integrity of the digital signature. A strong cryptographic hash produces the juridical proof that a document has not changed since the digital signature was created. Digital signature integrity is proven by calculating a cryptographic hash value of a copy of the document/information in question then comparing it to the decrypted cryptographic hash value in the digital signature. Equal comparison then may prove the integrity of the document or information.
The user's identity bound into the PKI certificate is used to offer proof of non-forge-ability and non-repudiation. The proof of non-forge-ability is dependent on the assurance that there is not more than one vouched-certificate that binds a public key to more than one user's identity.
The proof of non-repudiation requires there to exist juridical evidence that the owner of a public-private key pair has protected the private key sufficiently and without unawares in order that another user can not have digitally signed a document/information using that private key and therefore derogate the value of user's identity bound in the PKI certificate.
Note that a vouched-certificate is one that has been signed by another PKI user with their identity also bound in the certificate. Of course the voucher could possess a certificate which in turn may possess a voucher. This chained vouching produces a difficulty in that the chain must be reasonably finite in length in order to provide an efficient authentication process. The end of this chain possesses a voucher who is self-vouching. This requires the authentication procedure to have a means of trusting this final voucher. A difficulty in this authentication process is the need to be completely assured that each voucher in the chain must be certain of the identity about which they are attributing. Furthermore, the last member in the chain should be trustingly beyond reproach.
The mathematics of public key cryptography is so appealing that much effort has been expended to derive means of making the difficulties, especially those outlined above, more juridically acceptable. Rather than continue with this approach, certain illustrative implementations produce an alternative to the production of digital signatures without using public key infrastructure. In other words, non-PKI digital signatures.
Accordingly, certain illustrative implementations described herein propose a digital signature for “the masses” that produces a digital signature that is cryptographically equivalent to PKI digital signatures while expectantly achieving juridical acceptability. The techniques described herein, in connection with certain example embodiments, may lead to increased user acceptance due to more well-known and/or simpler (e.g., user friendly) implementations for achieving juridical approval.
An added attraction of certain illustrative implementations is the introduction of an Information Notary Public that may be focused on the typical user by providing the Information Notary Public service as a secure Cloud-Computing resource which minimizes user information coordination and management. With the understanding that Cloud-Computing is a model for enabling convenient, trusted, on-demand network access to a shared pool of configurable computing resources, such as, for example, networks, servers, storage, applications, and services, that can be rapidly provisioned and released with minimal management effort or service provider interaction.
Non-PKI Digital Signatures
Certain digital signatures applied to digital information may have properties to supply proof of: 1) document integrity; 2) document digital signature authenticity; 3) a non-forged signed document; 4) evidence of a non-reputable document signature; and 5) a tight binding of the digital identity of the signer to the signer and the digital document.
In certain illustrative implementations, proof of document integrity is offered by application of a cryptographic hash function(s) binding to demonstrate that the document is unchanged since the document/information was digitally signed. However, digital signatures require a binding of a user's identity value to the document/information just as is the case with PKI digital signatures. A difference is that encryption of the cryptographic hash function value of the document/information implicitly binds the PKI certificate user identity to the document/information. In contrast, certain illustrative implementations may explicitly bind an appropriate user identity directly with the document/information using the selected cryptographic hash function(s).
Due to the importance of the cryptographic binding function, it is useful to introduce a resilient variation of the binding by allowing the cryptographic binding to be composed of one or more hashing functions.
For example, using SHA-256 as a cryptographic binding works, but the process may well be made more resilient by applying SHA-256 and RIPEMD-160 as a compound digesting function. If either of these functions become cryptographically unsound the cryptographic binding remains in tact. Of course, in the unlikely event that both functions become cryptographically unsound then the binding is unsound. Accordingly, certain example embodiments may use the term cryptographic binding to imply the use of a compound digest function as the cryptographic binding.
A cryptographic binding can be accomplished in at least two ways. One way is for the cryptographic hash function to be applied on a concatenation of the document/information with the value of the appropriately chosen user identity value. This method is an efficient application of the cryptographic hash function(s). This efficiency may be very important when using processing resources with limited computing capacity especially if the cryptographic hash function is a time consuming function on the application processing resource.
A second means of producing a binding is to calculate separate cryptographic hash function values on the document/information and the appropriately chosen user identity. These two cryptographic hash function values may be concatenated whereby a cryptographic hash function can be applied to produce a binding of the document/information with the appropriately chosen user identity. While this technique may not be as efficient in certain respects and may require a more complex generation process, it may also allow applications to make independent decisions on the integrity of the individual parts, e.g.,—the document/information or the appropriately chosen user identity.
With the appropriate encoding, possibly using Abstract Syntax Notation One (ASN.1) or XML, the above noted techniques, or other possibilities could be readily used by certain exemplary implementations. These potential encodings could be subsequently decoded in an application that can produce evidentiary proof of the juridical value as exemplary use of a non-PKI digital signature. In certain instances, such proof may include naively comparing hashes (e.g., digital digests) of the signature and a re-created signature. In certain example embodiments, evidentiary proof may include proof that a secure time-stamp is in fact a valid time stamp for an associated digital signature. Further, non-PKI-based timestamps may independently validate the efficacy of a digital signature via publicly accessible digital witness information.
The choice of user identity cryptographically bound to the document/information may be relevant according to certain example embodiments. Given a user, denoted as U, who desires to digitally sign a document/information then user U must possess an Identity U (e.g., a digital identity) that is unique to, managed, and authenticated by an accessible identity service. A preferred identity service according to certain illustrative implementations is a network cloud-based identity service. The mentioned Identity U may have one or more of the following attributes.
Identity U
Identity U could be a structured container which relates identity attribute(s), IAi, to their actual value(s), Ui, to produce an Identity U which may be unique to an appropriate Identity Service. The structure could be a well-defined, ordered record of all of the identity components that comprise Identity U.
In another, possibly more versatile structure, the components could be a set of identity attributes of named tags, IAi, with related tag values, Ui. Either of these techniques could readily produce an Identity U. It will be appreciated that there are other possibilities for producing equivalent identities.
The structure may be determined by the requirements of the identity service to produce a unique identity associated with a given identity service. The following examples may be instructive.
An example of a structured container regarding a unique Identity JQ Public is:    John Quincy Public    JQPublic@ExampleIdentityService.comwhere the            first name field”, “John”, is coded into positions 1-16;        “middle name/initial field”, “Quincy”, is coded into positions 17-32;        “last name field”, “Public”, is coded into positions 33-64; and        “service identity field”,            “JQPublic@ExampleIdentityService.com”, is coded into positions 65-128.
An example of a named-tag identity attributes structure regarding a unique Identity JQ Public for the Example Tagged Identity Service is:
<data version=”2011.08.01.00”><Full_Name>   <First_Name value=”John” />   <Middle_Name value=”Quiggly” />   <Last_Name value=”Public” /></Full_Name><Address>   <Street>     123 Sidney Drive   </Street>   <City value=”Honolulu” />   <State value=”HI” />   <Zip_Code value=”96848” />   <Country value=”US” /></Address><Service url=”http://www.ExampleTaggedIdentityService.com” /><Claims value=”Author;Owner” /><User_Service_Identity>   jqpublic@exampletaggedidentityservice.com</User_Service_Identity></data>
To this point, an identity service is only necessary for assuring the service-relative uniqueness of the Identity U. The ultimate value of the identity service will be that of producing the mechanisms for fulfilling the requirements of a digital signature that does not use the elements of public key infrastructure (PKI). The Signed By U is the first exemplary implementation of the technology toward that end. However, before the illustrative implementation of Signed By U is discussed, a discussion of cloud-based services, particularly cloud-based identity service is provided.
Cloud-based Service
Certain exemplary implementations may apply the U.S. National Institute of Standards and Technology (NIST) definition of cloud computing. The NIST definition states:                Cloud computing is a model for enabling ubiquitous, convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications, and services) that can be rapidly provisioned and released with minimal management effort or service provider interaction.        
The amount of computing resources that may be needed to fulfill the requirements for digital signature services necessitates a number of service essentials. These include:
1) A service that can be quickly scaled and provisioned to meet the need. Commercial cloud services are being developed to offer virtually unlimited resources. By the same token these services can contract as demand wanes in order to be efficient and cost effective.
2) A service with broad network accessibility. Not only is broad network bandwidth required, but also, heterogeneous network accessibility is required for desktop, portable (laptop/tablet), and mobile services.
3) A service which does not require explicit user management or control.
4) A service that specifies and assures published security and privacy models that will affirm juridical necessity.
Accordingly, certain example embodiments may use such a model of cloud-based services. However, other example embodiments may not rely on such a model. In other words, the point to mentioning the model at all is to suggest that digital signature services may demand resources that are more readily met by such a service model. Services that are used according to certain exemplary implementations may be able to fulfill the security and privacy requirements laid out by each of the various forms of the non-PKI digital signature. The simplest form of the non-PKI digital signature is Signed By U. The utilization of cloud-based services is emphasized with respect to certain example embodiments described herein.
Signed By U
Signed By U for the purposes of certain exemplary implementations is a relation to a document(s)/information that is tightly and securely bound to an Identity U. The functional value of the mapping contains the value(s) that establish the temporal existence of the document(s)/information as well as the binding to an Identity U. Note that PKI-based digital signatures do not require proof of temporal existence, and in certain example embodiments such may not be required by non-PKI digital signatures. However, temporal existence of that which is signed may be a preferred approach of digital signatures as a secure and well-defined witness/attestation to the act of digitally signing therefore that importance is emphasized according to certain exemplary implementations. Relaxation of temporal qualifications for digital witnessing the act of signing may be possible but may not be expedient in certain instances. In other words, the act of witness generally tends to have a temporal nature.
Further, Signed By U is not required to be explicitly authenticated using Identity U by an identity service. Presumably the service which provides the temporal existence of the document(s)/information that is bound to Identity U requires some form of authentication for access to the service, but there is no strong requirement that the authentication is bound to Identity U. Moreover, the establishment of the temporal existence of the signing process creates an “early bird gets the worm” condition. Specifically, if a Signed By U condition is used to claim some unique identity attribute such as authorship or ownership and Signed By V registers similar claims, then the “signing” with the earliest temporal existence overrides the later digital signature and its temporal existence. Note, however, that such conditions can become significantly complex so that the crafting of intent of an identity attribute may be established with a certain level of specificity.
Signed By U may be considered “a weak signing condition” since the Identity U is not necessarily expressly authenticated by the identity service. Accordingly, this condition may be strengthened somewhat by the next condition.
Assuredly Signed By U
A document/information is Assuredly Signed By U if the document/information is associated with a Signed by U condition and U has been established as an authentic identity via an authentication service of an Identity U associated with the Signed by U condition. In other words, the authentication service for an Identity U may be a function of the Identity Service so that the Identity Service may be assured that the Identity of U is directly related to the user “U”.
This signing condition is stronger since the Identity U is cryptographically bound to the document/information while the Identity U is explicitly used as the primary user identity for the authentication process with the Identification Service.
Such techniques may be further adjusted with an identity which should be considered juridically stronger than the general Identity U.
Registered Identity U
A juridically stronger identity is a Registered Identity U. This manner of identity is generated by:
1) Having the identity service produce a document that defines the contractual terms and conditions for authentication of the identity service which is accepted by the requester of the Registered Identity U;
2) As part of the review and acceptance of the terms, cryptographically bind the contract to the authenticated Identity U associated with the requester by using the Registered Identity U;
3) Acceptably establish (e.g., securely) and authenticate a user utilizing an associated Identity U uniquely through a desirable identity service;
4) Produce the cryptographic binding of the contract to the registered identity service on the requester's computing/reviewing resource;
5) Validate the cryptographic binding by independently recalculating the binding of the contract with the Identity U for comparison to the value produced on the user's computing resource;
6) Establish the secure temporal existence of this contract and Registered Identity U to create the Registered identity U of an Identity U; and
7) Assemble for subsequent use as the Registered Identity U of an Identity U with the cryptographic binding of the contract document and the Identity U along with a secure temporal existence certification.
Subsequent use of this Registered Identity U establishes the terms and conditions recognized by the creating and authenticating identity service. Such an identity applied as part of a digital signature on a document/information should have significant juridical force.
Document/Information Digital Signature
The aforementioned application of a Registered Identity U for the creation of a Signed By U condition on a document/information may be considered a Document Digital Signature or Information Digital Signature.
Note that PKI does not necessarily enter into this process unless, implicitly, the secure temporal existence service utilizes PKI for creation of the secure temporal existence seal. Other forms of a secure temporal existence service offer appealing qualities such as widely-witnessed certificates of temporal existence. These certificates can be independently authenticated for proof of validity. Such secure temporal existence (e.g., a certificate thereof) may be establish based on techniques described in U.S. Publication 2012/0011359, the entire contents of which are hereby incorporated by reference.
A variant on Document/Information Digital Signature uses a Registered Identity of the Identity Service to produce the potential for a digital apostille notary service, producing an Information Notary Public.
Information Notary Public
An Information Notary Public may be a cloud-based identity service that possesses Registered Identity(s) of the Notary Service. In the case of an apostille notary service the Registered Identity of the Notary Service is established with an Apostille Identity service such as a State Identity Service. The notary service, responds to a request for notary services on a Document/Information Digital Signature by:
1) Authenticating the Registered Identity U associated with the Document/Information Digital Signature;
2) Generating a Document/Information Digital Signature on the above Document/Information Digital Signature associated with the authenticated Registered Identity U; and
3) Binding this “notarized” digital signature with the associated Document/Information Digital Signature.
Certain illustrative implementations may include several means of producing digital signatures on documents/information without necessarily using public key infrastructure (PKI). An aspect of certain illustrative implementations is that of devising a simple, typical user interface which is a secure means of accomplishing digital signatures for digital information. Another aspect of certain illustrative implementations is to utilize techniques that are familiar to a user's experience for managing digital information signatory matters in a manner similar to the management of signatory matters in the traditional paper world.
Signatory management using public key infrastructure (PKI) is mathematically and technologically appealing, but seems to be a source of mystery and confusion to The Celebrated Man In The Street (TC Mits). See the introduction of TC Mits from Lilian Lieber's book, “The Einstein Theory of Relativity: A Trip to the Fourth Dimension”. Certain illustrative implementations may not require special management of keys. Certain example embodiments may use authentication of a signer's identity as is the case with PKI digital signatures.
Note, too, forms of non-PKI digital signatures are bound to a proof of the temporal existence of the digital signature to its associated information object. Such may not be the case with standards-compliant PKI-based digital signatures. As previously mentioned, temporal existence of the digital signature can be replaced by other means of proof of authentication by the identity service for a light-weight digital signature. Using a temporal existence service as a binding to authentication by the identity service is a convenient and simple solution besides usefully adding proof of existence in time. Producing a signature for seemingly most transactions is accompanied by a reference to the temporal existence of the act of signing. Furthermore, if the temporal existence service uses widely-witnessed techniques for proof of temporal existence then independent validation of authentication is an added quality according to certain example embodiments.
It should be noted that the production of digital signatures accordingly to certain example implementations can be fulfilled using a mobile computing system such as a mobile smart phone as the user's digital signing agent. The smart phone can be used to assure content agreement as well as the agent for producing the secure binding of document to digital identity. Use of the smart phone along with cloud-based services may enhance the appeal of certain exemplary implementations.